<!DOCTYPE html>
<html lang="zh-Hans">
<head>
  <meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=2">
<meta name="theme-color" content="#222">
<meta name="generator" content="Hexo 4.2.1">
  <link rel="apple-touch-icon" sizes="180x180" href="/images/apple-touch-icon-next.png">
  <link rel="icon" type="image/png" sizes="32x32" href="/images/favicon-32x32-next.png">
  <link rel="icon" type="image/png" sizes="16x16" href="/images/favicon-16x16-next.png">
  <link rel="mask-icon" href="/images/logo.svg" color="#222">

<link rel="stylesheet" href="/css/main.css">


<link rel="stylesheet" href="/lib/font-awesome/css/all.min.css">
  <link rel="stylesheet" href="/lib/pace/pace-theme-minimal.min.css">
  <script src="/lib/pace/pace.min.js"></script>

<script id="hexo-configurations">
    var NexT = window.NexT || {};
    var CONFIG = {"hostname":"sophimp.gitee.io","root":"/","scheme":"Pisces","version":"7.8.0","exturl":false,"sidebar":{"position":"left","display":"post","padding":18,"offset":12,"onmobile":false},"copycode":{"enable":false,"show_result":false,"style":null},"back2top":{"enable":true,"sidebar":false,"scrollpercent":true},"bookmark":{"enable":false,"color":"#222","save":"auto"},"fancybox":false,"mediumzoom":false,"lazyload":false,"pangu":false,"comments":{"style":"tabs","active":null,"storage":true,"lazyload":false,"nav":null},"algolia":{"hits":{"per_page":10},"labels":{"input_placeholder":"Search for Posts","hits_empty":"We didn't find any results for the search: ${query}","hits_stats":"${hits} results found in ${time} ms"}},"localsearch":{"enable":false,"trigger":"auto","top_n_per_article":1,"unescape":false,"preload":false},"motion":{"enable":true,"async":false,"transition":{"post_block":"fadeIn","post_header":"slideDownIn","post_body":"slideDownIn","coll_header":"slideLeftIn","sidebar":"slideUpIn"}}};
  </script>

  <meta name="description" content="官方文档需要翻墙，这里备份一下， 方便没有翻墙或者暂时不能翻墙的小伙伴们查阅，但是，搞开发， 还是需要一个梯子， 不然受限太多了。">
<meta property="og:type" content="article">
<meta property="og:title" content="(官方文档)Android Verified Boot 2.0">
<meta property="og:url" content="http://sophimp.gitee.io/2019/08/26/android/rom/android_verify_boot_2/index.html">
<meta property="og:site_name" content="Sophimp&#39;s Space">
<meta property="og:description" content="官方文档需要翻墙，这里备份一下， 方便没有翻墙或者暂时不能翻墙的小伙伴们查阅，但是，搞开发， 还是需要一个梯子， 不然受限太多了。">
<meta property="article:published_time" content="2019-08-26T14:02:41.000Z">
<meta property="article:modified_time" content="2021-03-15T03:49:47.927Z">
<meta property="article:author" content="Sophimp">
<meta property="article:tag" content="AVB2.0">
<meta name="twitter:card" content="summary">

<link rel="canonical" href="http://sophimp.gitee.io/2019/08/26/android/rom/android_verify_boot_2/">


<script id="page-configurations">
  // https://hexo.io/docs/variables.html
  CONFIG.page = {
    sidebar: "",
    isHome : false,
    isPost : true,
    lang   : 'zh-Hans'
  };
</script>

  <title>(官方文档)Android Verified Boot 2.0 | Sophimp's Space</title>
  






  <noscript>
  <style>
  .use-motion .brand,
  .use-motion .menu-item,
  .sidebar-inner,
  .use-motion .post-block,
  .use-motion .pagination,
  .use-motion .comments,
  .use-motion .post-header,
  .use-motion .post-body,
  .use-motion .collection-header { opacity: initial; }

  .use-motion .site-title,
  .use-motion .site-subtitle {
    opacity: initial;
    top: initial;
  }

  .use-motion .logo-line-before i { left: initial; }
  .use-motion .logo-line-after i { right: initial; }
  </style>
</noscript>

</head>

<body itemscope itemtype="http://schema.org/WebPage">
  <div class="container use-motion">
    <div class="headband"></div>

	
	<script type="text/javascript" src="//cdn.bootcss.com/canvas-nest.js/1.0.0/canvas-nest.min.js"></script>
	

    <header class="header" itemscope itemtype="http://schema.org/WPHeader">
      <div class="header-inner"><div class="site-brand-container">
  <div class="site-nav-toggle">
    <div class="toggle" aria-label="Toggle navigation bar">
      <span class="toggle-line toggle-line-first"></span>
      <span class="toggle-line toggle-line-middle"></span>
      <span class="toggle-line toggle-line-last"></span>
    </div>
  </div>

  <div class="site-meta">

    <a href="/" class="brand" rel="start">
      <span class="logo-line-before"><i></i></span>
      <h1 class="site-title">Sophimp's Space</h1>
      <span class="logo-line-after"><i></i></span>
    </a>
      <p class="site-subtitle" itemprop="description">coding & thinking</p>
  </div>

  <div class="site-nav-right">
    <div class="toggle popup-trigger">
    </div>
  </div>
</div>




<nav class="site-nav">
  <ul id="menu" class="main-menu menu">
        <li class="menu-item menu-item-home">

    <a href="/" rel="section"><i class="fa fa-home fa-fw"></i>Home</a>

  </li>
        <li class="menu-item menu-item-archives">

    <a href="/archives/" rel="section"><i class="fa fa-archive fa-fw"></i>Archives</a>

  </li>
  </ul>
</nav>




</div>
    </header>

    
  <div class="back-to-top">
    <i class="fa fa-arrow-up"></i>
    <span>0%</span>
  </div>
  <div class="reading-progress-bar"></div>

  <a href="https://github.com/sophimp" class="github-corner" title="Follow me on GitHub" aria-label="Follow me on GitHub" rel="noopener" target="_blank"><svg width="80" height="80" viewBox="0 0 250 250" aria-hidden="true"><path d="M0,0 L115,115 L130,115 L142,142 L250,250 L250,0 Z"></path><path d="M128.3,109.0 C113.8,99.7 119.0,89.6 119.0,89.6 C122.0,82.7 120.5,78.6 120.5,78.6 C119.2,72.0 123.4,76.3 123.4,76.3 C127.3,80.9 125.5,87.3 125.5,87.3 C122.9,97.6 130.6,101.9 134.4,103.2" fill="currentColor" style="transform-origin: 130px 106px;" class="octo-arm"></path><path d="M115.0,115.0 C114.9,115.1 118.7,116.5 119.8,115.4 L133.7,101.6 C136.9,99.2 139.9,98.4 142.2,98.6 C133.8,88.0 127.5,74.4 143.8,58.0 C148.5,53.4 154.0,51.2 159.7,51.0 C160.3,49.4 163.2,43.6 171.4,40.1 C171.4,40.1 176.1,42.5 178.8,56.2 C183.1,58.6 187.2,61.8 190.9,65.4 C194.5,69.0 197.7,73.2 200.1,77.6 C213.8,80.2 216.3,84.9 216.3,84.9 C212.7,93.1 206.9,96.0 205.4,96.6 C205.1,102.4 203.0,107.8 198.3,112.5 C181.9,128.9 168.3,122.5 157.7,114.1 C157.9,116.9 156.7,120.9 152.7,124.9 L141.0,136.5 C139.8,137.7 141.6,141.9 141.8,141.8 Z" fill="currentColor" class="octo-body"></path></svg></a>


    <main class="main">
      <div class="main-inner">
        <div class="content-wrap">
          

          <div class="content post posts-expand">
            

    
  
  
  <article itemscope itemtype="http://schema.org/Article" class="post-block" lang="zh-Hans">
    <link itemprop="mainEntityOfPage" href="http://sophimp.gitee.io/2019/08/26/android/rom/android_verify_boot_2/">

    <span hidden itemprop="author" itemscope itemtype="http://schema.org/Person">
      <meta itemprop="image" content="/images/avatar.png">
      <meta itemprop="name" content="Sophimp">
      <meta itemprop="description" content="A dream begin">
    </span>

    <span hidden itemprop="publisher" itemscope itemtype="http://schema.org/Organization">
      <meta itemprop="name" content="Sophimp's Space">
    </span>
      <header class="post-header">
        <h1 class="post-title" itemprop="name headline">
          (官方文档)Android Verified Boot 2.0
        </h1>

        <div class="post-meta">
            <span class="post-meta-item">
              <span class="post-meta-item-icon">
                <i class="far fa-calendar"></i>
              </span>
              <span class="post-meta-item-text">Posted on</span>

              <time title="Created: 2019-08-26 22:02:41" itemprop="dateCreated datePublished" datetime="2019-08-26T22:02:41+08:00">2019-08-26</time>
            </span>
              <span class="post-meta-item">
                <span class="post-meta-item-icon">
                  <i class="far fa-calendar-check"></i>
                </span>
                <span class="post-meta-item-text">Edited on</span>
                <time title="Modified: 2021-03-15 11:49:47" itemprop="dateModified" datetime="2021-03-15T11:49:47+08:00">2021-03-15</time>
              </span>
            <span class="post-meta-item">
              <span class="post-meta-item-icon">
                <i class="far fa-folder"></i>
              </span>
              <span class="post-meta-item-text">In</span>
                <span itemprop="about" itemscope itemtype="http://schema.org/Thing">
                  <a href="/categories/Android/" itemprop="url" rel="index"><span itemprop="name">Android</span></a>
                </span>
            </span>

          
            <span class="post-meta-item" title="Views" id="busuanzi_container_page_pv" style="display: none;">
              <span class="post-meta-item-icon">
                <i class="fa fa-eye"></i>
              </span>
              <span class="post-meta-item-text">Views: </span>
              <span id="busuanzi_value_page_pv"></span>
            </span>
            <div class="post-description">官方文档需要翻墙，这里备份一下， 方便没有翻墙或者暂时不能翻墙的小伙伴们查阅，但是，搞开发， 还是需要一个梯子， 不然受限太多了。</div>

        </div>
      </header>

    
    
    
    <div class="post-body" itemprop="articleBody">

      
        <p><a href="https://blog.csdn.net/shangyexin/article/details/86649504" target="_blank" rel="noopener">译文</a></p>
<p>This repository contains tools and libraries for working with Android Verified Boot 2.0. Usually AVB is used to refer to this codebase.</p>
<h2 id="What-is-it"><a href="#What-is-it" class="headerlink" title="What is it?"></a>What is it?</h2><p>Verified boot is the process of assuring the end user of the integrity of the software running on a device. It typically starts with a read-only portion of the device firmware which loads code and executes it only after cryptographically verifying that the code is authentic and doesn’t have any known security flaws. AVB is one implementation of verified boot.</p>
<h2 id="The-VBMeta-struct"><a href="#The-VBMeta-struct" class="headerlink" title="The VBMeta struct"></a>The VBMeta struct</h2><p>The central data structure used in AVB is the VBMeta struct. This data structure contains a number of descriptors (and other metadata) and all of this data is cryptographically signed. Descriptors are used for image hashes, image hashtree metadata, and so-called chained partitions. A simple example is the following:</p>
<p>AVB with boot, system, and vendor</p>
<p>where the vbmeta partition holds the hash for the boot partition in a hash descriptor. For the system and vendor partitions a hashtree follows the filesystem data and the vbmeta partition holds the root hash, salt, and offset of the hashtree in hashtree descriptors. Because the VBMeta struct in the vbmeta partition is cryptographically signed, the boot loader can check the signature and verify it was made by the owner of key0 (by e.g. embedding the public part of key0) and thereby trust the hashes used for boot, system, and vendor.</p>
<p>A chained partition descriptor is used to delegate authority - it contains the name of the partition where authority is delegated as well as the public key that is trusted for signatures on this particular partition. As an example, consider the following setup:</p>
<p>AVB with a chained partition</p>
<p>In this setup the xyz partition has a hashtree for integrity-checking. Following the hashtree is a VBMeta struct which contains the hashtree descriptor with hashtree metadata (root hash, salt, offset, etc.) and this struct is signed with key1. Finally, at the end of the partition is a footer which has the offset of the VBMeta struct.</p>
<p>This setup allows the bootloader to use the chain partition descriptor to find the footer at the end of the partition (using the name in the chain partition descriptor) which in turns helps locate the VBMeta struct and verify that it was signed by key1 (using key1_pub stored in the chain partition descriptor). Crucially, because there’s a footer with the offset, the xyz partition can be updated without the vbmeta partition needing any changes.</p>
<p>The VBMeta struct is flexible enough to allow hash descriptors and hashtree descriptors for any partition to live in the vbmeta partition, the partition that they are used to integrity check (via a chain partition descriptor), or any other partition (via a chain partition descriptor). This allows for a wide range of organizational and trust relationships.</p>
<p>Chained partitions need not use a footer - it is permissible to have a chained partition point to a partition where the VBMeta struct is at the beginning (e.g. just like the vbmeta partition). This is useful for use-cases where all hash- and hashtree-descriptors for the partitions owned by an entire organization are stored in a dedicated partition, for example vbmeta_google. In this example the hashtree descriptor for system is in the vbmeta_google partition meaning that the bootloader doesn’t need to access the system partition at all which is helpful if the system partition is managed as a logical partition (via e.g. LVM techniques or similar).</p>
<h2 id="Rollback-Protection"><a href="#Rollback-Protection" class="headerlink" title="Rollback Protection"></a>Rollback Protection</h2><p>AVB includes Rollback Protection which is used to protect against known security flaws. Each VBMeta struct has a rollback index baked into it like the following:</p>
<p>AVB rollback indexes</p>
<p>These numbers are referred to as rollback_index[n] and are increased for each image as security flaws are discovered and fixed. Additionally the device stores the last seen rollback index in tamper-evident storage:</p>
<p>AVB stored rollback indexes</p>
<p>and these are referred to as stored_rollback_index[n].</p>
<p>Rollback protection is having the device reject an image unless rollback_index[n] &gt;= stored_rollback_index[n] for all n, and having the device increase stored_rollback_index[n] over time. Exactly how this is done is discussed in the Updating Stored Rollback Indexes section.</p>
<h2 id="A-B-Support"><a href="#A-B-Support" class="headerlink" title="A/B Support"></a>A/B Support</h2><p>AVB has been designed to work with A/B by requiring that the A/B suffix is never used in any partition names stored in descriptors. Here’s an example with two slots:</p>
<p>AVB with A/B partitions</p>
<p>Note how the rollback indexes differ between slots - for slot A the rollback indexes are [42, 101] and for slot B they are [43, 103].</p>
<p>In version 1.1 or later, avbtool supports –do_not_use_ab for add_hash_footer and add_hashtree_footer operations. This makes it possible to work with a partition that does not use A/B and should never have the prefix. This corresponds to the AVB_HASH[TREE]_DESCRIPTOR_FLAGS_DO_NOT_USE_AB flags.</p>
<h2 id="The-VBMeta-Digest"><a href="#The-VBMeta-Digest" class="headerlink" title="The VBMeta Digest"></a>The VBMeta Digest</h2><p>The VBMeta digest is a digest over all VBMeta structs including the root struct (e.g. in the vbmeta partition) and all VBMeta structs in chained partitions. This digest can be calculated at build time using avbtool calculate_vbmeta_digest and also at runtime using the avb_slot_verify_data_calculate_vbmeta_digest() function. It is also set on the kernel command-line as androidboot.vbmeta.digest, see the avb_slot_verify() documentation for exact details.</p>
<p>This digest can be used together with libavb in userspace inside the loaded operating system to verify authenticity of the loaded vbmeta structs. This is useful if the root-of-trust and/or stored rollback indexes are only available while running in the boot loader.</p>
<p>Additionally, if the VBMeta digest is included in hardware-backed attestation data a relying party can extract the digest and compare it with list of digests for known good operating systems which, if found, provides additional assurance about the device the application is running on.</p>
<p>For factory images of Pixel 3 and later devices, the pixel_factory_image_verify.py located in tools/transparency is a convenience tool for downloading, verifying and calcuating VBMeta Digests.</p>
<p>$ pixel_factory_image_verify.py <a href="https://dl.google.com/dl/android/aosp/image.zip" target="_blank" rel="noopener">https://dl.google.com/dl/android/aosp/image.zip</a><br>Fetching file from: <a href="https://dl.google.com/dl/android/aosp/image.zip" target="_blank" rel="noopener">https://dl.google.com/dl/android/aosp/image.zip</a><br>Successfully downloaded file.<br>Successfully unpacked factory image.<br>Successfully unpacked factory image partitions.<br>Successfully verified VBmeta.<br>Successfully calculated VBMeta Digest.<br>The VBMeta Digest for factory image is: 1f329b20a2dd69425e7a29566ca870dad51d2c579311992d41c9ba9ba05e170e<br>If the given argument is not an URL it considered to be a local file:</p>
<p>$ pixel_factory_image_verify.py image.zip<br>Tools and Libraries<br>This section contains information about the tools and libraries included in AVB.</p>
<p>avbtool and libavb<br>The main job of avbtool is to create vbmeta.img which is the top-level object for verified boot. This image is designed to go into the vbmeta partition (or, if using A/B, the slot in question e.g. vbmeta_a or vbmeta_b) and be of minimal size (for out-of-band updates). The vbmeta image is cryptographically signed and contains verification data (e.g. cryptographic digests) for verifying boot.img, system.img, and other partitions/images.</p>
<p>The vbmeta image can also contain references to other partitions where verification data is stored as well as a public key indicating who should sign the verification data. This indirection provides delegation, that is, it allows a 3rd party to control content on a given partition by including their public key in vbmeta.img. By design, this authority can be easily revoked by simply updating vbmeta.img with new descriptors for the partition in question.</p>
<p>Storing signed verification data on other images - for example boot.img and system.img - is also done with avbtool.</p>
<p>In addition to avbtool, a library - libavb - is provided. This library performs all verification on the device side e.g. it starts by loading the vbmeta partition, checks the signature, and then goes on to load the boot partition for verification. This library is intended to be used in both boot loaders and inside Android. It has a simple abstraction for system dependencies (see avb_sysdeps.h) as well as operations that the boot loader or OS is expected to implement (see avb_ops.h). The main entry point for verification is avb_slot_verify().</p>
<p>Android Things has specific requirements and validation logic for the vbmeta public key. An extension is provided in libavb_atx which performs this validation as an implementation of libavb’s public key validation operation (see avb_validate_vbmeta_public_key() in avb_ops.h).</p>
<p>Files and Directories<br>libavb/<br>An implementation of image verification. This code is designed to be highly portable so it can be used in as many contexts as possible. This code requires a C99-compliant C compiler. Part of this code is considered internal to the implementation and should not be used outside it. For example, this applies to the avb_rsa.[ch] and avb_sha.[ch] files. System dependencies expected to be provided by the platform is defined in avb_sysdeps.h. If the platform provides the standard C runtime avb_sysdeps_posix.c can be used.<br>libavb_atx/<br>An Android Things Extension for validating public key metadata.<br>libavb_user/<br>Contains an AvbOps implementation suitable for use in Android userspace. This is used in boot_control.avb and avbctl.<br>libavb_ab/<br>An experimental A/B implementation for use in boot loaders and AVB examples. NOTE: This code is DEPRECATED and you must define AVB_AB_I_UNDERSTAND_LIBAVB_AB_IS_DEPRECATED to use it. The code will be removed Jun 1 2018.<br>boot_control/<br>An implementation of the Android boot_control HAL for use with boot loaders using the experimental libavb_ab A/B stack. NOTE: This code is DEPRECATED and will be removed Jun 1 2018.<br>contrib/<br>Contains patches needed in other projects for interoperability with AVB. For example, contrib/linux/4.4 has the patches for Linux kernel 4.4, which are generated by git format-patch.<br>Android.bp<br>Build instructions for building libavb (a static library for use on the device), host-side libraries (for unit tests), and unit tests.<br>avbtool<br>A tool written in Python for working with images related to verified boot.<br>test/<br>Unit tests for abvtool, libavb, libavb_ab, and libavb_atx.<br>tools/avbctl/<br>Contains the source-code for a tool that can be used to control AVB at runtime in Android.<br>examples/uefi/<br>Contains the source-code for a UEFI-based boot-loader utilizing libavb/ and libavb_ab/.<br>examples/things/<br>Contains the source-code for a slot verification suitable for Android Things.<br>README.md<br>This file.<br>docs/<br>Contains documentation files.<br>Portability<br>The libavb code is intended to be used in bootloaders in devices that will load Android or other operating systems. The suggested approach is to copy the appropriate header and C files mentioned in the previous section into the boot loader and integrate as appropriate.</p>
<p>As the libavb/ codebase will evolve over time integration should be as non-invasive as possible. The intention is to keep the API of the library stable however it will be broken if necessary. As for portability, the library is intended to be highly portable, work on both little- and big-endian architectures and 32- and 64-bit. It’s also intended to work in non-standard environments without the standard C library and runtime.</p>
<p>If the AVB_ENABLE_DEBUG preprocessor symbol is set, the code will include useful debug information and run-time checks. Production builds should not use this. The preprocessor symbol AVB_COMPILATION should be set only when compiling the libraries. The code must be compiled into a separate library.</p>
<p>Applications using the compiled libavb library must only include the libavb/libavb.h file (which will include all public interfaces) and must not have the AVB_COMPILATION preprocessor symbol set. This is to ensure that internal code that may be change in the future (for example avb_sha.[ch] and avb_rsa.[ch]) will not be visible to application code.</p>
<p>Versioning and Compatibility<br>AVB uses a version number with three fields - the major, minor, and sub version. Here’s an example version number</p>
<pre><code>1.4.3
^ ^ ^
| | |</code></pre><p>the major version —+ | |<br>the minor version —–+ |<br>  the sub version ——-+<br>The major version number is bumped only if compatibility is broken, e.g. a struct field has been removed or changed. The minor version number is bumped only if a new feature is introduced, for example a new algorithm or descriptor has been added. The sub version number is bumped when bugs are fixed or other changes not affecting compatibility are made.</p>
<p>The AvbVBMetaImageHeader struct (as defined in the avb_vbmeta_image.h) carries the major and minor version number of libavb required to verify the struct in question. This is stored in the required_libavb_version_major and required_libavb_version_minor fields. Additionally this struct contains a textual field with the version of avbtool used to create the struct, for example “avbtool 1.4.3” or “avbtool 1.4.3 some_board Git-4589fbec”.</p>
<p>Note that it’s entirely possible to have a AvbVBMetaImageHeader struct with</p>
<p>required_libavb_version_major = 1<br>required_libavb_version_minor = 0<br>avbtool_release_string = “avbtool 1.4.3”<br>if, for example, creating an image that does not use any features added after AVB version 1.0.</p>
<p>Adding New Features<br>If adding a new feature for example a new algorithm or a new descriptor then AVB_VERSION_MINOR in avb_version.h and avbtool must be bumped and AVB_VERSION_SUB should be set to zero.</p>
<p>Unit tests MUST be added to check that</p>
<p>The feature is used if - and only if - suitable commands/options are passed to avbtool.<br>The required_version_minor field is set to the bumped value if - and only if - the feature is used. Also add tests to check that the correct value is output when –print_required_libavb_version is used.<br>If AVB_VERSION_MINOR has already been bumped since the last release there is obviously no need to bump it again.</p>
<p>Using avbtool<br>The content for the vbmeta partition can be generated as follows:</p>
<p>$ avbtool make_vbmeta_image                                                    <br>    [–output OUTPUT]                                                          <br>    [–algorithm ALGORITHM] [–key /path/to/key_used_for_signing_or_pub_key]   <br>    [–public_key_metadata /path/to/pkmd.bin] [–rollback_index NUMBER]        <br>    [–include_descriptors_from_image /path/to/image.bin]                      <br>    [–setup_rootfs_from_kernel /path/to/image.bin]                            <br>    [–chain_partition part_name:rollback_index_location:/path/to/key1.bin]    <br>    [–signing_helper /path/to/external/signer]                                <br>    [–signing_helper_with_files /path/to/external/signer_with_files]          <br>    [–print_required_libavb_version]                                          <br>    [–append_to_release_string STR]<br>An integrity footer containing the hash for an entire partition can be added to an existing image as follows:</p>
<p>$ avbtool add_hash_footer                                                      <br>    –partition_name PARTNAME –partition_size SIZE                            <br>    [–image IMAGE]                                                            <br>    [–algorithm ALGORITHM] [–key /path/to/key_used_for_signing_or_pub_key]   <br>    [–public_key_metadata /path/to/pkmd.bin] [–rollback_index NUMBER]        <br>    [–hash_algorithm HASH_ALG] [–salt HEX]                                   <br>    [–include_descriptors_from_image /path/to/image.bin]                      <br>    [–setup_rootfs_from_kernel /path/to/image.bin]                            <br>    [–output_vbmeta_image OUTPUT_IMAGE] [–do_not_append_vbmeta_image]        <br>    [–signing_helper /path/to/external/signer]                                <br>    [–signing_helper_with_files /path/to/external/signer_with_files]          <br>    [–print_required_libavb_version]                                          <br>    [–append_to_release_string STR]                                           <br>    [–calc_max_image_size]                                                    <br>    [–do_not_use_ab]                                                          <br>    [–use_persistent_digest]<br>An integrity footer containing the root digest and salt for a hashtree for a partition can be added to an existing image as follows. The hashtree is also appended to the image.</p>
<p>$ avbtool add_hashtree_footer                                                  <br>    –partition_name PARTNAME –partition_size SIZE                            <br>    [–image IMAGE]                                                            <br>    [–algorithm ALGORITHM] [–key /path/to/key_used_for_signing_or_pub_key]   <br>    [–public_key_metadata /path/to/pkmd.bin] [–rollback_index NUMBER]        <br>    [–hash_algorithm HASH_ALG] [–salt HEX] [–block_size SIZE]               <br>    [–include_descriptors_from_image /path/to/image.bin]                      <br>    [–setup_rootfs_from_kernel /path/to/image.bin]                            <br>    [–setup_as_rootfs_from_kernel]                                            <br>    [–output_vbmeta_image OUTPUT_IMAGE] [–do_not_append_vbmeta_image]        <br>    [–do_not_generate_fec] [–fec_num_roots FEC_NUM_ROOTS]                    <br>    [–signing_helper /path/to/external/signer]                                <br>    [–signing_helper_with_files /path/to/external/signer_with_files]          <br>    [–print_required_libavb_version]                                          <br>    [–append_to_release_string STR]                                           <br>    [–calc_max_image_size]                                                    <br>    [–do_not_use_ab]                                                          <br>    [–use_persistent_digest]<br>The size of an image with integrity footers can be changed using the resize_image command:</p>
<p>$ avbtool resize_image                                                         <br>    –image IMAGE                                                              <br>    –partition_size SIZE<br>The integrity footer on an image can be removed from an image. The hashtree can optionally be kept in place.</p>
<p>$ avbtool erase_footer –image IMAGE [–keep_hashtree]<br>For hash- and hashtree-images the vbmeta struct can also be written to an external file via the –output_vbmeta_image option and one can also specify that the vbmeta struct and footer not be added to the image being operated on.</p>
<p>The hashtree and FEC data in an image can be zeroed out with the following command:</p>
<p>$ avbtool zero_hashtree –image IMAGE<br>This is useful for trading compressed image size for having to reculculate the hashtree and FEC at runtime. If this is done the hashtree and FEC data is set to zero except for the first eight bytes which are set to the magic ZeRoHaSH. Either the hashtree or FEC data or both may be zeroed this way so applications should check for the magic both places. Applications can use the magic to detect if recalculation is needed.</p>
<p>To calculate the maximum size of an image that will fit in a partition of a given size after having used the avbtool add_hash_footer or avbtool add_hashtree_footer commands on it, use the –calc_max_image_size option:</p>
<p>$ avbtool add_hash_footer –partition_size $((10<em>1024</em>1024)) <br>    –calc_max_image_size<br>10416128</p>
<p>$ avbtool add_hashtree_footer –partition_size $((10<em>1024</em>1024)) <br>    –calc_max_image_size<br>10330112<br>To calculate the required libavb version that would be put in the vbmeta struct when using make_vbmeta_image, add_hash_footer, and add_hashtree_footer commands use the –print_required_libavb_version option:</p>
<p>$ avbtool make_vbmeta_image <br>    –algorithm SHA256_RSA2048 –key /path/to/key.pem <br>    –include_descriptors_from_image /path/to/boot.img <br>    –include_descriptors_from_image /path/to/system.img <br>    –print_required_libavb_version<br>1.0<br>The –signing_helper option can be used in make_vbmeta_image, add_hash_footer and add_hashtree_footer commands to specify any external program for signing hashes. The data to sign (including padding e.g. PKCS1-v1.5) is fed via STDIN and the signed data is returned via STDOUT. If –signing_helper is present in a command line, the –key option need only contain a public key. Arguments for a signing helper are algorithm and public key. If the signing helper exits with a non-zero exit code, it means failure.</p>
<p>Here’s an example invocation:</p>
<p>/path/to/my_signing_program SHA256_RSA2048 /path/to/publickey.pem<br>The –signing_helper_with_files is similar to –signing_helper except that a temporary file is used to communicate with the helper instead of STDIN and STDOUT. This is useful in situations where the signing helper is using code which is outputting diagnostics on STDOUT instead of STDERR. Here’s an example invocation</p>
<p>/path/to/my_signing_program_with_files SHA256_RSA2048 <br>  /path/to/publickey.pem /tmp/path/to/communication_file<br>where the last positional argument is a file that contains the data to sign. The helper should write the signature in this file.</p>
<p>The append_vbmeta_image command can be used to append an entire vbmeta blob to the end of another image. This is useful for cases when not using any vbmeta partitions, for example:</p>
<p>$ cp boot.img boot-with-vbmeta-appended.img<br>$ avbtool append_vbmeta_image                       <br>    –image boot-with-vbmeta-appended.img           <br>    –partition_size SIZE_OF_BOOT_PARTITION         <br>    –vbmeta_image vbmeta.img<br>$ fastboot flash boot boot-with-vbmeta-appended.img<br>The verify_image command can be used to verify the contents of several image files at the same time. When invoked on an image the following checks are performed:</p>
<p>If the image has a VBMeta struct the signature is checked against the embedded public key. If the image doesn’t look like vbmeta.img then a footer is looked for and used if present.</p>
<p>If the option –key is passed then a .pem file is expected and it’s checked that the embedded public key in said VBMeta struct matches the given key.</p>
<p>All descriptors in the VBMeta struct are checked in the following way:</p>
<p>For a hash descriptor the image file corresponding to the partition name is loaded and its digest is checked against that in the descriptor.<br>For a hashtree descriptor the image file corresponding to the partition name is loaded and the hashtree is calculated and its root digest compared to that in the descriptor.<br>For a chained partition descriptor its contents is compared against content that needs to be passed in via the –expected_chain_partition options. The format for this option is similar to that of the –chain_partition option. If there is no –expected_chain_partition descriptor for the chain partition descriptor the check fails.<br>Here’s an example for a setup where the digests for boot.img and system.img are stored in vbmeta.img which is signed with my_key.pem. It also checks that the chain partition for partition foobar uses rollback index 8 and that the public key in AVB format matches that of the file foobar_vendor_key.avbpubkey:</p>
<p>$ avbtool verify_image <br>     –image /path/to/vbmeta.img <br>     –key my_key.pem <br>     –expect_chained_partition foobar:8:foobar_vendor_key.avbpubkey</p>
<p>Verifying image /path/to/vbmeta.img using key at my_key.pem<br>vbmeta: Successfully verified SHA256_RSA4096 vbmeta struct in /path_to/vbmeta.img<br>boot: Successfully verified sha256 hash of /path/to/boot.img for image of 10543104 bytes<br>system: Successfully verified sha1 hashtree of /path/to/system.img for image of 1065213952 bytes<br>foobar: Successfully verified chain partition descriptor matches expected data<br>In this example the verify_image command verifies the files vbmeta.img, boot.img, and system.img in the directory /path/to. The directory and file extension of the given image (e.g. /path/to/vbmeta.img) is used together with the partition name in the descriptor to calculate the filenames of the images holding hash and hashtree images.</p>
<p>The verify_image command can also be used to check that a custom signing helper works as intended.</p>
<p>The calculate_vbmeta_digest command can be used to calculate the vbmeta digest of several image files at the same time. The result is printed as a hexadecimal string either on STDOUT or a supplied path (using the –output option).</p>
<p>$ avbtool calculate_vbmeta_digest <br>     –hash_algorithm sha256 <br>     –image /path/to/vbmeta.img<br>a20fdd01a6638c55065fe08497186acde350d6797d59a55d70ffbcf41e95c2f5<br>In this example the calculate_vbmeta_digest command loads the vbmeta.img file. If this image has one or more chain partition descriptors, the same logic as the verify_image command is used to load files for these (e.g. it assumes the same directory and file extension as the given image). Once all vbmeta structs have been loaded, the digest is calculated (using the hash algorithm given by the –hash_algorithm option) and printed out.</p>
<p>Build System Integration<br>In Android, AVB is enabled by the BOARD_AVB_ENABLE variable</p>
<p>BOARD_AVB_ENABLE := true<br>This will make the build system create vbmeta.img which will contain a hash descriptor for boot.img, a hashtree descriptor for system.img, a kernel-cmdline descriptor for setting up dm-verity for system.img and append a hash-tree to system.img. If the build system is set up such that one or many of vendor.img / product.img / system_ext.img / odm.img are being built, the hash-tree for each of them will also be appended to the image respectively, and their hash-tree descriptors will be included into vbmeta.img accordingly.</p>
<p>By default, the algorithm SHA256_RSA4096 is used with a test key from the external/avb/test/data directory. This can be overriden by the BOARD_AVB_ALGORITHM and BOARD_AVB_KEY_PATH variables to use e.g. a 4096-bit RSA key and SHA-512:</p>
<p>BOARD_AVB_ALGORITHM := SHA512_RSA4096<br>BOARD_AVB_KEY_PATH := /path/to/rsa_key_4096bits.pem<br>Remember that the public part of this key needs to be available to the bootloader of the device expected to verify resulting images. Use avbtool extract_public_key to extract the key in the expected format (AVB_pk in the following). If the device is using a different root of trust than AVB_pk the –public_key_metadata option can be used to embed a blob (AVB_pkmd in the following) that can be used to e.g. derive AVB_pk. Both AVB_pk and AVB_pkmd are passed to the validate_vbmeta_public_key() operation when verifying a slot.</p>
<p>Some devices may support the end-user configuring the root of trust to use, see the Device Specific Notes section for details.</p>
<p>Devices can be configured to create additional vbmeta partitions as chained partitions in order to update a subset of partitions without changing the top-level vbmeta partition. For example, the following variables create vbmeta_system.img as a chained vbmeta image that contains the hash-tree descriptors for system.img and system_ext.img. vbmeta_system.img itself will be signed by the specified key and algorithm.</p>
<p>BOARD_AVB_VBMETA_SYSTEM := system system_ext<br>BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem<br>BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048<br>BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1<br>Note that the hash-tree descriptors for system.img and system_ext.img will be included only in vbmeta_system.img, but not vbmeta.img. With the above setup, partitions system.img, system_ext.img and vbmeta_system.img can be updated independently - but as a group - of the rest of the partitions, or as part of the traditional updates that update all the partitions.</p>
<p>Currently build system supports building chained vbmeta images of vbmeta_system.img (BOARD_AVB_VBMETA_SYSTEM) and vbmeta_vendor.img (BOARD_AVB_VBMETA_VENDOR).</p>
<p>To prevent rollback attacks, the rollback index should be increased on a regular basis. The rollback index can be set with the BOARD_AVB_ROLLBACK_INDEX variable:</p>
<p> BOARD_AVB_ROLLBACK_INDEX := 5<br>If this is not set, the rollback index defaults to 0.</p>
<p>The variable BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS can be used to specify additional options passed to avbtool make_vbmeta_image. Typical options to be used here include –prop, –prop_from_file, –chain_partition, –public_key_metadata, and –signing_helper.</p>
<p>The variable BOARD_AVB_BOOT_ADD_HASH_FOOTER_ARGS can be used to specify additional options passed to avbtool add_hash_footer for boot.img. Typical options to be used here include –hash_algorithm and –salt.</p>
<p>The variable BOARD_AVB_SYSTEM_ADD_HASHTREE_FOOTER_ARGS can be used to specify additional options passed to avbtool add_hashtree_footer for system.img. Typical options to be used here include –hash_algorithm, –salt, –block_size, and –do_not_generate_fec.</p>
<p>The variable BOARD_AVB_VENDOR_ADD_HASHTREE_FOOTER_ARGS can be used to specify additional options passed to avbtool add_hashtree_footer for vendor.img. Typical options to be used here include –hash_algorithm, –salt, –block_size, and –do_not_generate_fec.</p>
<p>The variable BOARD_AVB_DTBO_ADD_HASH_FOOTER_ARGS can be used to specify additional options passed to avbtool add_hash_footer for dtbo.img. Typical options to be used here include –hash_algorithm and –salt.</p>
<p>Build system variables (such as PRODUCT_SUPPORTS_VERITY_FEC) used for previous version of Verified Boot in Android are not used in AVB.</p>
<p>A/B related build system variables can be found here.</p>
<p>Device Integration<br>This section discusses recommendations and best practices for integrating libavb with a device boot loader. It’s important to emphasize that these are just recommendations so the use of the word must should be taken lightly.</p>
<p>Additionally term HLOS is used in this chapter to refer to the High Level Operating System. This obviously includes Android (including other form-factors than phones) but could also be other operating systems.</p>
<p>System Dependencies<br>The libavb library is written in a way so it’s portable to any system with a C99 compiler. It does not require the standard C library however the boot loader must implement a simple set of system primitives required by libavb such as avb_malloc(), avb_free(), and avb_print().</p>
<p>In addition to the system primitives, libavb interfaces with the boot loader through the supplied AvbOps struct. This includes operations to read and write data from partitions, read and write rollback indexes, check if the public key used to make a signature should be accepted, and so on.</p>
<p>Locked and Unlocked mode<br>AVB has been designed to support the notion of the device being either LOCKED state or UNLOCKED state as used in Android.</p>
<p>In the context of AVB, the LOCKED state means that verification errors are fatal whereas in UNLOCKED state they are not. If the device is UNLOCKED pass AVB_SLOT_VERIFY_FLAGS_ALLOW_VERIFICATION_ERROR flag in the flags parameter of avb_slot_verify() and treat verification errors including</p>
<p>AVB_SLOT_VERIFY_RESULT_ERROR_PUBLIC_KEY_REJECTED<br>AVB_SLOT_VERIFY_RESULT_ERROR_VERIFICATION<br>AVB_SLOT_VERIFY_RESULT_ERROR_ROLLBACK_INDEX<br>as non-fatal. If the device is in the LOCKED state, don’t pass the AVB_SLOT_VERIFY_FLAGS_ALLOW_VERIFICATION_ERROR flag in the flags parameter of avb_slot_verify() and only treat AVB_SLOT_VERIFY_RESULT_OK as non-fatal.</p>
<p>On Android, device state may be altered through the fastboot interface using, e.g. fastboot flashing lock (to transition to the LOCKED state) and fastboot flashing unlock (to transition to the UNLOCKED state).</p>
<p>The device must only allow state transitions (e.g. from LOCKED to UNLOCKED or UNLOCKED to LOCKED) after asserting physical presence of the user. If the device has a display and buttons this is typically done by showing a dialog and requiring the user to confirm or cancel using physical buttons.</p>
<p>All user data must be cleared when transitioning from the LOCKED to the UNLOCKED state (including the userdata partition and any NVRAM spaces). Additionally all stored_rollback_index[n] locations must be cleared (all elements must be set to zero). Similar action (erasing userdata, NVRAM spaces, and stored_rollback_index[n] locations) shall also happening when transitioning from UNLOCKED to LOCKED. If the device is required to use full disk encryption, then a less intensive wipe is required for UNLOCKED to LOCKED. Depending on the device form-factor and intended use, the user should be prompted to confirm before any data is erased.</p>
<p>Tamper-evident Storage<br>In this document, tamper-evident means that it’s possible to detect if the HLOS has tampered with the data, e.g. if it has been overwritten.</p>
<p>Tamper-evident storage must be used for stored rollback indexes, keys used for verification, device state (whether the device is LOCKED or UNLOCKED), and named persistent values. If tampering has been detected the corresponding AvbOps operation should fail by e.g. returning AVB_IO_RESULT_ERROR_IO. It is especially important that verification keys cannot be tampered with since they represent the root-of-trust.</p>
<p>If verification keys are mutable they must only be set by the end user, e.g. it must never be set at the factory or store or any intermediate point before the end user. Additionally, it must only be possible to set or clear a key while the device is in the UNLOCKED state.</p>
<p>Named Persistent Values<br>AVB 1.1 introduces support for named persistent values which must be tamper evident and allows AVB to store arbitrary key-value pairs. Integrators may limit support for these values to a set of fixed well-known names, a maximum value size, and / or a maximum number of values.</p>
<p>Persistent Digests<br>Using a persistent digest for a partition means the digest (or root digest in the case of a hashtree) is not stored in the descriptor but is stored in a named persistent value. This allows configuration data which may differ from device to device to be verified by AVB. It must not be possible to modify the persistent digest when the device is in the LOCKED state, except if a digest does not exist it may be initialized.</p>
<p>To specify that a descriptor should use a persistent digest, use the –use_persistent_digest option for the add_hash_footer or add_hashtree_footer avbtool operations. Then, during verification of the descriptor, AVB will look for the digest in the named persistent value avb.persistent_digest.$(partition_name) instead of in the descriptor itself.</p>
<p>For hashtree descriptors using a persistent digest, the digest value will be available for substitution into kernel command line descriptors using a token of the form $(AVB_FOO_ROOT_DIGEST) where ‘FOO’ is the uppercase partition name, in this case for the partition named ‘foo’. The token will be replaced by the digest in hexadecimal form.</p>
<p>By default, when the –use_persistent_digest option is used with add_hash_footer or add_hashtree_footer, avbtool will generate a descriptor with no salt rather than the typical default of generating a random salt equal to the digest length. This is because the digest value is stored in persistent storage and thus cannot change over time. An alternative option would be to manually provide a random salt using –salt, but this salt would need to remain unchanged for the life of the device once the persistent digest value was written.</p>
<p>Updating Stored Rollback Indexes<br>In order for Rollback Protection to work the bootloader will need to update the stored_rollback_indexes[n] array on the device prior to transferring control to the HLOS. If not using A/B this is straightforward - just update it to what’s in the AVB metadata for the slot before booting. In pseudo-code it would look like this:</p>
<p>// The |slot_data| parameter should be the AvbSlotVerifyData returned<br>// by avb_slot_verify() for the slot we’re about to boot.<br>//<br>bool update_stored_rollback_indexes_for_slot(AvbOps* ops,<br>                                             AvbSlotVerifyData* slot_data) {<br>    for (int n = 0; n &lt; AVB_MAX_NUMBER_OF_ROLLBACK_INDEX_LOCATIONS; n++) {<br>        uint64_t rollback_index = slot_data-&gt;rollback_indexes[n];<br>        if (rollback_index &gt; 0) {<br>            AvbIOResult io_ret;<br>            uint64_t current_stored_rollback_index;</p>
<pre><code>        io_ret = ops-&gt;read_rollback_index(ops, n, &amp;current_stored_rollback_index);
        if (io_ret != AVB_IO_RESULT_OK) {
            return false;
        }

        if (rollback_index &gt; current_stored_rollback_index) {
            io_ret = ops-&gt;write_rollback_index(ops, n, rollback_index);
            if (io_ret != AVB_IO_RESULT_OK) {
                return false;
            }
        }
    }
}
return true;</code></pre><p>}<br>However if using A/B more care must be taken to still allow the device to fall back to the old slot if the update didn’t work.</p>
<p>For an HLOS like Android where rollback is only supported if the updated OS version is found to not work, stored_rollback_index[n] should only be updated from slots that are marked as SUCCESSFUL in the A/B metadata. The pseudo-code for that is as follows where is_slot_is_marked_as_successful() comes from the A/B stack in use:</p>
<p>if (is_slot_is_marked_as_successful(slot-&gt;ab_suffix)) {<br>    if (!update_stored_rollback_indexes_for_slot(ops, slot)) {<br>        // TODO: handle error.<br>    }<br>}<br>For an HLOS where it‘s possible to roll back to a previous version, stored_rollback_index[n] should be set to the largest possible value allowing all bootable slots to boot. This approach is implemented in AVB’s experimental (and now deprecated) A/B stack libavb_ab, see the avb_ab_flow() implementation. Note that this requires verifying all bootable slots at every boot and this may impact boot time.</p>
<p>Recommended Bootflow<br>The recommended boot flow for a device using AVB is as follows:</p>
<p>Recommended AVB boot flow</p>
<p>Notes:</p>
<p>The device is expected to search through all A/B slots until it finds a valid OS to boot. Slots that are rejected in the LOCKED state might not be rejected in the UNLOCKED state, (e.g. when UNLOCKED any key can be used and rollback index failures are allowed), so the algorithm used for selecting a slot varies depending on what state the device is in.</p>
<p>If no valid OS (that is, no bootable A/B slot) can be found, the device cannot boot and has to enter repair mode. It is device-dependent what this looks like. If the device has a screen it must convey this state to the user.</p>
<p>If the device is LOCKED, only an OS signed by an embedded verification key (see the previous section) shall be accepted. Additionally, rollback_index[n] as stored in the verified image must be greater or equal than what’s in stored_rollback_index[n] on the device (for all n) and the stored_rollback_index[n] array is expected to be updated as specified in the previous section.</p>
<p>If the key used for verification was set by the end user, and the device has a screen, it must show a warning with the key fingerprint to convey that the device is booting a custom OS. The warning must be shown for at least 10 seconds before the boot process continues. If the device does not have a screen, other ways must be used to convey that the device is booting a custom OS (lightbars, LEDs, etc.).<br>If the device is UNLOCKED, there is no requirement to check the key used to sign the OS nor is there any requirement to check or update rollback stored_rollback_index[n] on the device. Because of this the user must always be shown a warning about verification not occurring.</p>
<p>It is device-dependent how this is implemented since it depends on the device form-factor and intended usage. If the device has a screen and buttons (for example if it’s a phone) the warning is to be shown for at least 10 seconds before the boot process continues. If the device does not have a screen, other ways must be used to convey that the device is UNLOCKED (lightbars, LEDs, etc.).<br>Booting Into Recovery<br>On Android devices not using A/B, the recovery partition usually isn‘t updated along with other partitions and therefore can’t be referenced from the main vbmeta partition.</p>
<p>It’s still possible to use AVB to protect this partition (and others) by signing these partitions and passing the AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION flag to avb_slot_verify(). In this mode, the key used to sign each requested partition is verified by the validate_public_key_for_partition() operation which is also used to return the rollback index location to be used.</p>
<p>Handling dm-verity Errors<br>By design, hashtree verification errors are detected by the HLOS and not the bootloader. AVB provides a way to specify how the error should be handled through the hashtree_error_mode parameter in the avb_slot_verify() function. Possible values include</p>
<p>AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE means that the HLOS will invalidate the current slot and restart. On devices with A/B this would lead to attempting to boot the other slot (if it’s marked as bootable) or it could lead to a mode where no OS can be booted (e.g. some form of repair mode). In Linux this requires a kernel built with CONFIG_DM_VERITY_AVB.</p>
<p>AVB_HASHTREE_ERROR_MODE_RESTART means that the OS will restart without the current slot being invalidated. Be careful using this mode unconditionally as it may introduce boot loops if the same hashtree verification error is hit on every boot.</p>
<p>AVB_HASHTREE_ERROR_MODE_EIO means that an EIO error will be returned to the application.</p>
<p>AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO means that either the RESTART or EIO mode is used, depending on state. This mode implements a state machine whereby RESTART is used by default and when the AVB_SLOT_VERIFY_FLAGS_RESTART_CAUSED_BY_HASHTREE_CORRUPTION is passed to avb_slot_verify() the mode transitions to EIO. When a new OS has been detected the device transitions back to the RESTART mode.</p>
<p>To do this persistent storage is needed - specifically this means that the passed in AvbOps will need to have the read_persistent_value() and write_persistent_value() operations implemented. The name of the persistent value used is avb.managed_verity_mode and 32 bytes of storage is needed.<br>AVB_HASHTREE_ERROR_MODE_LOGGING means that errors will be logged and corrupt data may be returned to applications. This mode should be used for ONLY diagnostics and debugging. It cannot be used unless verification errors are allowed.</p>
<p>The value passed in hashtree_error_mode is essentially just passed on through to the HLOS through the the androidboot.veritymode, androidboot.veritymode.managed, and androidboot.vbmeta.invalidate_on_error kernel command-line parameters in the following way:</p>
<p>androidboot.veritymode    androidboot.veritymode.managed    androidboot.vbmeta.invalidate_on_error<br>AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE    enforcing    (unset)    yes<br>AVB_HASHTREE_ERROR_MODE_RESTART    enforcing    (unset)    (unset)<br>AVB_HASHTREE_ERROR_MODE_EIO    eio    (unset)    (unset)<br>AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO    eio or enforcing    yes    (unset)<br>AVB_HASHTREE_ERROR_MODE_LOGGING    ignore_corruption    (unset)    (unset)<br>The only exception to this table is that if the AVB_VBMETA_IMAGE_FLAGS_HASHTREE_DISABLED flag is set in the top-level vbmeta, then androidboot.veritymode is set to disabled and androidboot.veritymode.managed and androidboot.vbmeta.invalidate_on_error are unset.</p>
<p>Which mode should I use for my device?<br>This depends entirely on the device, how the device is intended to be used, and the desired user experience.</p>
<p>For Android devices the AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO mode should be used. Also see the Boot Flow section on source.android.com for the kind of UX and UI the boot loader should implement.</p>
<p>If the device doesn’t have a screen or if the HLOS supports multiple bootable slots simultaneously it may make more sense to just use AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE.</p>
<p>Android Specific Integration<br>On Android, the boot loader must set the androidboot.verifiedbootstate parameter on the kernel command-line to indicate the boot state. It shall use the following values:</p>
<p>green: If in LOCKED state and the key used for verification was not set by the end user.<br>yellow: If in LOCKED state and the key used for verification was set by the end user.<br>orange: If in the UNLOCKED state.<br>Device Specific Notes<br>This section contains information about how AVB is integrated into specific devices. This is not an exhaustive list.</p>
<p>Pixel 2<br>On the Pixel 2 and Pixel 2 XL the boot loader supports a virtual partition with the name avb_custom_key. Flashing and erasing this partition only works in the UNLOCKED state. Setting the custom key is done like this:</p>
<p>avbtool extract_public_key –key key.pem –output pkmd.bin<br>fastboot flash avb_custom_key pkmd.bin<br>Erasing the key is done by erasing the virtual partition:</p>
<p>fastboot erase avb_custom_key<br>When the custom key is set and the device is in the LOCKED state it will boot images signed with both the built-in key as well as the custom key. All other security features (including rollback-protection) are in effect, e.g. the only difference is the root of trust to use.</p>
<p>When booting an image signed with a custom key, a yellow screen will be shown as part of the boot process to remind the user that the custom key is in use.</p>
<p>Version History<br>Version 1.1<br>Version 1.1 adds support for the following:</p>
<p>A 32-bit flags element is added to hash and hashtree descriptors.<br>Support for partitions which don’t use A/B.<br>Tamper-evident named persistent values.<br>Persistent digests for hash or hashtree descriptors.<br>Version 1.0<br>All features not explicitly listed under a later version are supported by 1.0.</p>
<p>Powered by Gitiles| Privacy</p>

    </div>

    
    
    

      <footer class="post-footer">
          <div class="post-tags">
              <a href="/tags/AVB2-0/" rel="tag"># AVB2.0</a>
          </div>

        


        
    <div class="post-nav">
      <div class="post-nav-item">
    <a href="/2019/08/24/android/rom/boot/modify_boot_img/" rel="prev" title="boot.img的定制">
      <i class="fa fa-chevron-left"></i> boot.img的定制
    </a></div>
      <div class="post-nav-item">
    <a href="/2019/09/02/android/rom/how_to_build_twrp/" rel="next" title="(译) 如何编译 TWRP recovery">
      (译) 如何编译 TWRP recovery <i class="fa fa-chevron-right"></i>
    </a></div>
    </div>
      </footer>
    
  </article>
  
  
  



          </div>
          

<script>
  window.addEventListener('tabs:register', () => {
    let { activeClass } = CONFIG.comments;
    if (CONFIG.comments.storage) {
      activeClass = localStorage.getItem('comments_active') || activeClass;
    }
    if (activeClass) {
      let activeTab = document.querySelector(`a[href="#comment-${activeClass}"]`);
      if (activeTab) {
        activeTab.click();
      }
    }
  });
  if (CONFIG.comments.storage) {
    window.addEventListener('tabs:click', event => {
      if (!event.target.matches('.tabs-comment .tab-content .tab-pane')) return;
      let commentClass = event.target.classList[1];
      localStorage.setItem('comments_active', commentClass);
    });
  }
</script>

        </div>
          
  
  <div class="toggle sidebar-toggle">
    <span class="toggle-line toggle-line-first"></span>
    <span class="toggle-line toggle-line-middle"></span>
    <span class="toggle-line toggle-line-last"></span>
  </div>

  <aside class="sidebar">
    <div class="sidebar-inner">

      <ul class="sidebar-nav motion-element">
        <li class="sidebar-nav-toc">
          Table of Contents
        </li>
        <li class="sidebar-nav-overview">
          Overview
        </li>
      </ul>

      <!--noindex-->
      <div class="post-toc-wrap sidebar-panel">
          <div class="post-toc motion-element"><ol class="nav"><li class="nav-item nav-level-2"><a class="nav-link" href="#What-is-it"><span class="nav-number">1.</span> <span class="nav-text">What is it?</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#The-VBMeta-struct"><span class="nav-number">2.</span> <span class="nav-text">The VBMeta struct</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#Rollback-Protection"><span class="nav-number">3.</span> <span class="nav-text">Rollback Protection</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#A-B-Support"><span class="nav-number">4.</span> <span class="nav-text">A&#x2F;B Support</span></a></li><li class="nav-item nav-level-2"><a class="nav-link" href="#The-VBMeta-Digest"><span class="nav-number">5.</span> <span class="nav-text">The VBMeta Digest</span></a></li></ol></div>
      </div>
      <!--/noindex-->

      <div class="site-overview-wrap sidebar-panel">
        <div class="site-author motion-element" itemprop="author" itemscope itemtype="http://schema.org/Person">
    <img class="site-author-image" itemprop="image" alt="Sophimp"
      src="/images/avatar.png">
  <p class="site-author-name" itemprop="name">Sophimp</p>
  <div class="site-description" itemprop="description">A dream begin</div>
</div>
<div class="site-state-wrap motion-element">
  <nav class="site-state">
      <div class="site-state-item site-state-posts">
          <a href="/archives/">
        
          <span class="site-state-item-count">86</span>
          <span class="site-state-item-name">posts</span>
        </a>
      </div>
      <div class="site-state-item site-state-categories">
            <a href="/categories/">
        <span class="site-state-item-count">19</span>
        <span class="site-state-item-name">categories</span></a>
      </div>
      <div class="site-state-item site-state-tags">
            <a href="/tags/">
        <span class="site-state-item-count">89</span>
        <span class="site-state-item-name">tags</span></a>
      </div>
  </nav>
</div>
  <div class="links-of-author motion-element">
      <span class="links-of-author-item">
        <a href="https://github.com/sophimp" title="GitHub → https:&#x2F;&#x2F;github.com&#x2F;sophimp" rel="noopener" target="_blank"><i class="fab fa-github fa-fw"></i>GitHub</a>
      </span>
      <span class="links-of-author-item">
        <a href="mailto:sophimp2020@126.com" title="E-Mail → mailto:sophimp2020@126.com" rel="noopener" target="_blank"><i class="fa fa-envelope fa-fw"></i>E-Mail</a>
      </span>
  </div>



      </div>

    </div>
  </aside>
  <div id="sidebar-dimmer"></div>


      </div>
    </main>

    <footer class="footer">
      <div class="footer-inner">
        

        

<div class="copyright">
  
  &copy; 
  <span itemprop="copyrightYear">2021</span>
  <span class="with-love">
    <i class="fa fa-heart"></i>
  </span>
  <span class="author" itemprop="copyrightHolder">Sophimp</span>
</div>

<!--
  <div class="powered-by">Powered by <a href="https://hexo.io/" class="theme-link" rel="noopener" target="_blank">Hexo</a> & <a href="https://pisces.theme-next.org/" class="theme-link" rel="noopener" target="_blank">NexT.Pisces</a>
  </div>
-->

        
<div class="busuanzi-count">
  <script async src="https://busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js"></script>
    <span class="post-meta-item" id="busuanzi_container_site_uv" style="display: none;">
      <span class="post-meta-item-icon">
        <i class="fa fa-user"></i>
      </span>
      <span class="site-uv" title="Total Visitors">
        <span id="busuanzi_value_site_uv"></span>
      </span>
    </span>
    <span class="post-meta-divider">|</span>
    <span class="post-meta-item" id="busuanzi_container_site_pv" style="display: none;">
      <span class="post-meta-item-icon">
        <i class="fa fa-eye"></i>
      </span>
      <span class="site-pv" title="Total Views">
        <span id="busuanzi_value_site_pv"></span>
      </span>
    </span>
</div>








      </div>
    </footer>
  </div>

  
  <script src="/lib/anime.min.js"></script>
  <script src="/lib/velocity/velocity.min.js"></script>
  <script src="/lib/velocity/velocity.ui.min.js"></script>

<script src="/js/utils.js"></script>

<script src="/js/motion.js"></script>


<script src="/js/schemes/pisces.js"></script>


<script src="/js/next-boot.js"></script>




  















  

  

</body>
</html>
